This is a useful feature for CD pipeline automation — the interactive volume recreation prompt is a common friction point in CI/CD environments. A few thoughts on the implementation:

Label naming convention

com.docker.compose.volume.recreate-when-spec-updated follows the existing Docker label namespace convention well. However, consider whether a shorter, more ergonomic alias like com.docker.compose.recreate=on-spec-change would be easier to remember. Looking at the existing Compose label space, verbose names are the norm, so the proposed name is consistent.

Scope: volumes only, or also other resources?

The same "recreate on spec change" problem applies to networks (e.g., network subnet changes) and potentially configs/secrets. While it's fine to scope this PR to volumes only, it would be worth noting in the PR description whether this label pattern is intended to be extensible to other resource types in the future, or if it's intentionally volume-specific.

Safety consideration: data loss risk

Reproducing a named volume destroys existing data. The label effectively silences a prompt that exists specifically to prevent accidental data loss. The implementation should clearly document this in:

1. The label's inline comment in the code
2. The Compose spec documentation (reference docs for labels)
3. Potentially a warning logged to stderr even when the label is set (e.g., WARN: Volume 'mydata' is being recreated due to spec change (label: com.docker.compose.volume.recreate-when-spec-updated)) so operators have an audit trail

CI workflow example

A concrete usage example in the PR description would help reviewers understand the target use case:

volumes:
  my_data:
    labels:
      com.docker.compose.volume.recreate-when-spec-updated: "true"

This makes it immediately clear whether the label value matters (boolean string) or just the presence of the label key is sufficient.

Good feature for automation-first workflows. The main thing I'd want to see before merge is explicit data-loss documentation.

I checked the code and couldn't find any other resource types that currently support this kind of recreation behavior. Because of that, I'd prefer to keep the scope limited to volumes for now.

I'm also not a big fan of a value-based label such as com.docker.compose.recreate=on-spec-change.

At the moment, the behavior is essentially a yes/no decision, similar to how the --yes flag works. A boolean-style label seems simpler and easier to understand. If we introduce additional recreation policies in the future, we can revisit the label format then.

@Quantum0uasar I updated the code comments and added warning logs to show what will happen when the volume spec changes. But I couldn't find where to add the documentation. Should I add it to docs/reference/compose_up.md?